$ type BLS32044.RELEASE_NOTES











                              CHAPTER 1

                     VAX BLISS V4.4 RELEASE NOTES




This document contains information about VAX BLISS-32 Version V4.4 and
previous versions.

This document is organized into four chapters:


      o  Chapter 1 provides an overview of this file.

      o  Chapter   2   provides    information    on    compatibility,
         restrictions, and documentation errors.

      o  Chapter 3 provides information on new features.

      o  Chapter 4 provides a list of the maintenance  fixes  included
         in the VAX BLISS-32 V4.4 compiler.























                                 1-1












                              CHAPTER 2

                         COMPATIBILITY NOTES




This chapter describes the differences between  VAX  BLISS-32  Version
4.3  and  Version  V4.4.  It also describes all known restrictions and
documentation errors.



2.1  COMPATIBILITY

This section describes the compatibility between VAX BLISS-32  Version
4.3 and the new Version V4.4.



2.1.1  Source Compatibility

The source language accepted by the VAX BLISS-32 Version V4.3 compiler
is  upwardly  compatible  with  that  accepted by the new Version V4.4
compiler.



2.1.2  Object Compatibility

The object files produced by the VAX BLISS-32 Version 4.3 compiler are
upwardly  compatible  with the Version V4.4 object files.  They can be
mixed freely in the same executable image.



2.1.3  Image Compatibility

The images linked with VAX BLISS-32 V4.4 object modules  are  strictly
compatible with similar images using V4.3 modules.





                                 2-1
























COMPATIBILITY NOTES
COMPATIBILITY


2.1.4  Library Files

The library files produced by a VAX BLISS-32 Version 4.3 compiler will
be accepted by the VAX BLISS-32 Version V4.4 compiler.



2.1.5  Behavior Differences

You should notice no differences in behavior when migrating from a VAX
BLISS-32 Version 4.3 compiler to VAX BLISS-32 Version V4.4.




2.2  KNOWN RESTRICTIONS

This section includes all  known  restrictions  in  the  VAX  BLISS-32
Version  V4.4  compiler.  Where possible, temporary solutions to these
restrictions are provided.




PROBLEM:  The following code fragment:

                d = 0;
                .....
                WHILE .d NEQ 0 DO
                    BEGIN
                    ....
                    x = 66 / .d;        ! Assume "d" never written
                    ...
                    IF .y THEN EXITLOOP
                    END

          will cause a zero-divide  exception  during  execution  when
          compiled  with  normal  optimization.  The compiler believes
          that the expression "66/.d" is loop invariant and moves  the
          computation out of the loop.













                                 2-2





















                                                   COMPATIBILITY NOTES
                                                    KNOWN RESTRICTIONS


SOLUTION: In this particular case, the expression can be rewritten as:

                WHILE 1 DO
                    BEGIN
                    .....
                    IF .d EQL 0 THEN EXITLOOP;
                    ....
                    x = 66 / .d;
                    .....
                    END;

          In this case, the expression cannot  be  moved  out  of  the
          loop.




PROBLEM:  Incorrect code generated for structure  definitions  of  the
          form:

                STRUCTURE BAD[I,P,S]= [%UPVAL]
                    (IF .I THEN BAD ELSE BAD + .BAD<16,16>)<P,S>;

                OWN X: BAD[];
                LOCAL T;

                T = .X[.T,0,12];

          "X" is loaded into a register in the  THEN-branch,  but  the
          ELSE-branch uses the register without loading it.

SOLUTION: This is the result of a design flaw  in  the  way  structure
          references  are  expanded.  BLISS semantics guarantee that a
          structure actual-parameter is evaluated only once.  This  is
          implemented  by treating the first occurrence of a structure
          formal  as  if  it  were  a  BIND  declaration.   The  other
          occurrences  of  the structure formal are then treated as if
          they were uses of the "imaginary" bind-name.  This choice of
          implementation  fails  when  the  first  occurrence  of  the
          structure formal is in conditional flow.  The problem can be
          avoided by ensuring that the first occurrence of each formal
          is outside  of  conditional  flow.   The  example  structure
          should be written as:

                STRUCTURE GOOD[I,P,S] = [%UPVAL]
                (GOOD; IF .I THEN GOOD ELSE GOOD + .GOOD<16,16>)<P,S>;

          Note that  the  "structure-name"  is  the  zeroth  structure
          formal parameter.  The formals "I", "P", and "S" are already
          outside  of  conditional  flow,  so   they   are   processed
          correctly.   This  change  will  cause  the  compiler to use


                                 2-3





















COMPATIBILITY NOTES
KNOWN RESTRICTIONS


          slightly  more  memory,  but  the  resulting  code  will  be
          correct.  There also should be no reduction in optimization.

          Be aware that no problem will  occur  when  the  conditional
          flow is constant folded at compile time, or when there is no
          conditional flow in the structure body.




PROBLEM:  The following code fragment:

                STRUCTURE
                    s1[] = [1] s1,
                    s2[] = [1] s1[s2];
                GLOBAL ROUTINE  r (x : REF s2) = x[];

          will cause an internal compiler error to occur.

SOLUTION: Like the previous problem, this is a design flaw in the  way
          structure  references  are  expanded.   When  one  structure
          references another structure within a structure declaration,
          bindings  become  indeterminate  during  evaluation  of  the
          structure reference.  The solution is to avoid  the  use  of
          such constructs in your program.




PROBLEM:  If  uninitialized  variable  checking  is  in  effect,   the
          compiler  occasionally  generates  spurious  messages when a
          variable is initialized in one branch of  an  IF,  CASE,  or
          SELECT  in  a  loop  and  then  referenced  in another.  For
          example:

                LOCAL X, FIRST_TIME,...;
                    FIRST_TIME = 1;
                WHILE condition
                DO
                    BEGIN
                    IF .FIRST_TIME
                    THEN
                        X = 0
                    ELSE
                        X = .X + 1;
                    FIRST_TIME = 0;
                    . . .
                    END;

          The compiler will report that X is uninitialized in "X =  .X
          + 1".


                                 2-4





















                                                   COMPATIBILITY NOTES
                                                    KNOWN RESTRICTIONS


SOLUTION: The  simplest  and  best  solution  is  to  initialize  such
          variables  before  they appear in the loop.  You can do this
          with an assignment or by using an INITIAL attribute  on  the
          variable declaration.

          You can also suppress  uninitialized  variable  messages  by
          using  the  /CHECK =NOINIT qualifier on the compiler command
          line.



2.3  DOCUMENTATION ERRORS

This section includes all known  documentation  errors  in  the  BLISS
Language Reference Manual and the VAX BLISS-32 User Manual.

     o  No known errors




2.4  DOCUMENTATION OMISSIONS

This section includes all known omissions from the documentation.

Several error messages are missing from Appendix E of the VAX BLISS-32
User Manual:

     o  Missing error message NOTUSEDCONF.

        269 Usage of register <integer> conflicts with NOTUSED
            definition in routine's linkage

            Explanation:  There is a conflict between  the  use  of  a
            register  in  a  REGISTER  or  BUILTIN declaration and the
            current routine's user-defined linkage, which defines  the
            register as NOTUSED.

            User Action:  Either remove the register's number from the
            NOTUSED  list,  or  use  another  register  number  in the
            REGISTER or BUILTIN declaration.

     o  Missing error message RETREGCONF.

            270 Valued routine's linkage should not define
                value-return register <integer> as NOTUSED

            Explanation:  There is a conflict between the  declaration
            of  a  valued  routine  and its linkage, which defines the
            value-return register as NOTUSED.



                                 2-5





















COMPATIBILITY NOTES
DOCUMENTATION OMISSIONS


            User Action:  Remove the  value-return  register's  number
            from the NOTUSED list.

     o  Missing warning message WAPCUSE.

            271 BUILTIN PC has unpredictable value
                and may cause a run-time fault

            Explanation:  The use of the program counter register (PC)
            can  lead to a run-time fault.  The contents of the PC are
            unpredictable, and certain uses are illegal (such as using
            the PC as an index register).

            User Action:  To get the  current  value  of  the  program
            counter,  consider  calling  a  routine which examines the
            stack for its return address and then returns that  value.
            Make  sure your use of BUILTIN PC is legal with respect to
            the VAX architecture.

     o  Missing warning message ERRPLACESEEN.

            272 Placeholder encountered

            Explanation:  A placeholder (text bracketed by [~ ~] or {~
            ~} or <~ ~>) occurred in the source file.

            User Action:  Delete the  placeholder  or  replace  it  by
            appropriate source code.

     o  Missing warning message ERRBADPLACE.

            273 Syntax error in placeholder

            Explanation:   A   syntactically   incorrect   placeholder
            occurred in the source file.

            User Action:  This message is currently used for the  case
            where  a placeholder is followed by one or two dots.  If a
            placeholder followed by dots (not a list  placeholder)  is
            what  is  intended,  the action should be to leave a blank
            between the end of the placeholder and the following  dot.
            If  a list placeholder is wanted, it should be followed by
            three dots.

     o  Missing warning message ERRPLACEUNBALANCED.

            274 Placeholder not terminated before end of line

            Explanation:    A    placeholder    contains    unbalanced
            placeholder  brackets,  or  is not ended before the end of
            the line.


                                 2-6





















                                                   COMPATIBILITY NOTES
                                               DOCUMENTATION OMISSIONS


            User Action:  Balance the brackets, and  ensure  that  the
            placeholder does not cross a line boundary.

     o  Missing error message WAOFFSETTRUNC.

            275 Reference to operand in instruction at offset <integer> was trun
cated; use ADDRESSING_MODE attribute

            Explanation:  Correct code  to  access  one  of  the  next
            instruction's  operands  cannot  be  generated because the
            reference to that operand has to be truncated to fit  into
            a  word-sized  field  in  the instruction.  The field is a
            word  because  that  is  BLISS's  default  size  for   the
            relative-offset mechanism of refering to symbols.

            User  Action:   Use  the  ADDRESSING_MODE   attribute   to
            increase  the  size  of the relative-offset field from the
            default  size  for  the  symbol  corresponding   to   this
            instruction's operand.



































                                 2-7












                              CHAPTER 3

                             NEW FEATURES



This is a maintenace-only release of BLISS-32.  No new  features  have
been added with this release.





































                                 3-1












                              CHAPTER 4

                MAINTENANCE CORRECTIONS FOR VAX BLISS



This chapter describes all changes made for the V4.4  release  of  the
VAX  BLISS-32  compiler.  It summarizes all corrections made as of the
date the kit was built.



      o  When compiling a module containing  the  following  structure
         reference with the /ANALYSIS_DATA qualifier:

                 X = .VECTOR[ UPLIT(0, 1, 2), .Y];

         the compiler got Internal Compiler Error 4006.  This  problem
         has been fixed.


      o  SCA LOAD gets an internal error when loading a .ANA file  for
         a module that contained the sequence:

                 BIND X = Y+4;   ! BIND to a name expression

                 LNKG (X, ...);  ! General routine call to X

                 LNKG (X, ...);  ! Second general routine call to X

         This problem has been fixed.


      o  When compiling with the /ANALYSIS_DATA  qualifier,  a  module
         containing  a  structure  reference  that contained a call to
         CH$Compare, the compiler got an Internal Compiler Error 4003.
         This problem has been fixed.


      o  When compiling the following module with  the  /ANALYSIS_DATA
         qualifier:

                 module test(addressing_mode(external=general)) =


                                 4-1

























MAINTENANCE CORRECTIONS FOR VAX BLISS


                 ! There should be a BEGIN here

                 macro
                    set_of(set_size) =
                        vector[((set_size)+%bpval-1)/%bpval]
                        %;
                 end
                 eludom

         the compiler got an Internal Compiler Error 4006.   This  has
         been fixed.


      o  Executable code at module level (legal only if the  code  can
         be  folded to a constant at run time) could lead to an Access
         Violation.  This could happen when an "IF"  occured  in  that
         code in a no-value-required context.  This has been fixed.


      o  An Access Violation would occur when compiling the  following
         module:

                 module BINDBUG = begin
                 bind
                     PC_LEX_TABLE = 5 initial;     ! syntax error here...
                 routine R =
                     begin
                     register
                         PC_LEX : initial(PC_LEX_TABLE);
                     .PC_LEX                       ! ...causes an ACCVIO here.
                     end;
                 end
                 eludom
         The literal value ("5") followed by a delimiter which was not
         ";"  caused one of the compiler's internal data structures to
         become corrupt,  thus  causing  the  eventual  ACCVIO.   This
         problem has been fixed.


      o  (SPR 11-R11-61330) A code sequence is  generated  which  does
         not  correspond  to  the  semantics of the source.  This is a
         rare problem, and it is  difficult  to  specify  what  source
         programs  could  lead  to it, as it depends on the compiler's
         assignment of temporary results to registers.

         This problem is  due  to  the  incorrect  application  of  an
         optimization  called "move merging".  After code selection, a
         sequence of object code looked like this:

             1)    MOVL R4, R9
             2)    MOVL R8, (R0)+
             3)    MOVL R9, (R0)+


                                 4-2





















                                 MAINTENANCE CORRECTIONS FOR VAX BLISS


             4)    MOVL R3, R8

         Lines 2 and 3 were merged to a MOVQ:

             1)    MOVL R4, R9
             2)    MOVQ R8, (R0)+
             4)    MOVL R3, R8

         Now line 1 was moved over the merged lines  and  merged  with
         line 4 to give the result below:

             2)    MOVQ R8, (R0)+
             4)    MOVQ R3, R8

         This last move was incorrect, as line 1's change in the value
         of R9 is not legal to move over line 2's use of R9.

         This problem has been fixed.


      o  An Internal Compiler Error 0 could occur for certain programs
         containing complex loops due to an incorrect application of a
         loop optimization.  This problem has been fixed.


      o  Change the implementation of CH$TRANSLATE and CH$FIND_SUB due
         to  a  change in the VAX architecture which would have slowed
         down the code that was previously generated.


      o  An incorrect DST (Debugger Symbol Table) was generated for  a
         CASE  construct under certain condition involving code motion
         optimizations.  The incorrect DST  caused  the  "SET  COUNTER
         PROGRAM  BY  LINE"  command  in  PCA  to fail with a reserved
         operand fault error.  This problem has been fixed.


      o  If the loop index of an INCR or DECR  loop  appeared  on  the
         right-hand  side  of  an  AND or OR, the AND or OR expression
         might be moved out of the loop as an incorrect optimization:

             DECR i FROM 10 TO 0 DO
                 IF (.y AND .i ) + 1  ! This expression was treated
                 THEN                 ! as loop-invariant.
                     :


         This problem has been fixed.






                                 4-3





















MAINTENANCE CORRECTIONS FOR VAX BLISS


      o  The compiler incorrectly performed a cross-jump  optimization
         when  it  merged  CALLs  to several FORWARD-declared routines
         into a single CALL to just one of the routines.  This problem
         has been fixed.


      o  Use of a built-in such as LOCC with output parameters in flow
         context  could  cause  incorrect  code  to be generated.  The
         incorrect code would fail to store an output  result  to  the
         output parameter.  This problem has been fixed.

             IF LOCC(.A, .B, .C; D, E)  ! "E" does not get the LOCC result -
             THEN                       ! it's stored in a random location.
                  :



      o  Numerous enhancements were made to  the  generation  of  DSTs
         (records  in  the  .OBJ file for use by the debugger).  These
         were in the area of improvements of the association  of  line
         numbers  with  the  program counter of a running program.  In
         particular, a line number is  now  associated  with  the  RET
         instruction.


      o  When the following  REQUIRE  file  was  compiled,  after  the
         expected (and correct) error message, the compiler would fail
         to handle a condition and  produce  a  register  dump.   This
         problem has been fixed.

                 macro A(X) = 1 %;

                 A(%quotename SIGNED BYTE);


      o  Use of BUILTIN PC as an  index  used  to  cause  an  Internal
         Compiler  Error.   This was replaced by a warning to the user
         that use of the PC can lead to run-time faults, and that  the
         PC's contents are always unpredictable.


      o  Bad code might  be  generated  to  fetch  from  a  STACKLOCAL
         variable,  if  the  variable  had  the  INITAL attribute, the
         INITIAL value was changed within  the  block  containing  the
         STACKLOCAL  variable  and  the  block  was  within  a looping
         construct.  There would also have to  be  another  STACKLOCAL
         variable  at  a parallel nesting depth (such as in a parallel
         loop)  before  the  one  with  the  error,  and  that   other
         STACKLOCAL  would  have  to have the same effective offset in
         the stack.

         The incorrect  code  would  treat  the  variable's  value  as


                                 4-4





















                                 MAINTENANCE CORRECTIONS FOR VAX BLISS


         loop-invariant.  This problem has been fixed.


      o  Bad code might be generated for sequences like the following:

             IF ...
             THEN
                 BEGIN
                 A_Routine_Call( Symbol )  ! Or "Symbol = <new value>;"
                     :
                 <expression> OR .Symbol   ! "AND" had the problem as well.
                 END
             ELSE
                 BEGIN
                 <expression> OR .Symbol
                 END;

         The calculation of the value of the "OR" (or the "AND") would
         be  moved  forward  to before the IF.  This was incorrect, as
         the routine call could have changed the  value  of  "Symbol".
         Similarly, code for an expression involving and "AND" or "OR"
         could be moved out of a loop as a  loop-invariant  expression
         even  though  the  loop contained a routine call which should
         have prevented such movement.  This problem has been fixed.


      o  BIND  expressions  might  not  be  fully  evaluated  at   the
         beginning  of  a  block,  (contrary  to the definition in the
         manual), in such a way as to cause  the  wrong  value  to  be
         used.  This problem has been fixed.

         The problem could arise in code of the following form:

             BIND
                Bind_Name = .<Bind_Expression>;

             <loop of some sort>
                 BEGIN
                 Bind_Name              ! Use of BIND_NAME
                   :
                 <Bind_Expression> = 0; ! Side effect happened here;
                 END;                   ! new value of BIND_NAME is 0.



      o  Symbolization  of  offsets  could  be  misleading  when   the
         compiler  had  replaced FP-relative addressing by SP-relative
         addressing.   The  symbolization  in  the  listing  has  been
         improved.  This does not affect assemblable code.





                                 4-5





















MAINTENANCE CORRECTIONS FOR VAX BLISS


      o  A very complex routine with many  variables  was  incorrectly
         compiled:   one  register  was  used  to  hold  two variables
         simultaneously.  This problem has been fixed.


      o  When an LSE placeholder is encountered in a source  file,  it
         will  now be flagged with a single error message (Placeholder
         encountered), rather than giving lots of error messages about
         individual characters and words in the placeholder.


      o  The compiler's data flow analysis routines could not handle a
         combination  of  loop-optimizations  if  they  followed  in a
         particular order:  this  lead  to  an  inconsistent  internal
         representation  of  the routine and thus an Internal Compiler
         Error.  The example below is not all  that  is  required  for
         this problem to show up, but illustrates its rarity.

             <e<f>>         ! An expression and sub-expression
             WHILE ... DO BEGIN
                 IF ...
                 THEN
                     <e<f>> ! are also used inside a loop
                            ! in an IF, and also on...
                 IF ...
                 THEN
                     <e<f>> ! one branch of another IF
                 ELSE       ! where only the sub-expression
                     <f>    ! is on its second branch
                 END        ! can cause this problem.





      o  A new warning was added to detect truncation  of  offsets  in
         instruction  operands.   This  truncation  can  arise  when a
         reference is made to a location in the $CODE$ PSECT more than
         32767  bytes away.  The recommended user action is use of the
         ADDRESSING_MODE attribute to increase the size of the  offset
         field to that particular symbol.













                                 4-6

$